fix: forward cancellation token to toolkit installer subprocesses#409
fix: forward cancellation token to toolkit installer subprocesses#409sLightlyDev wants to merge 2 commits into
Conversation
The pip/venv exec calls in the Deepnote toolkit installer were started without the CancellationToken, so cancellation was only checked between calls. Cancelling during a multi-minute pip install did nothing until the install finished, leaving the Stop button unresponsive. Pass the token into every processService.exec call (and thread it through isToolkitInstalled) so cancelling now terminates the running subprocess immediately.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #409 +/- ##
===========================
===========================
🚀 New features to boost your workflow:
|
📝 WalkthroughWalkthroughThis PR propagates a cancellation token through deepnote-toolkit installation subprocesses. The installer now forwards the token to venv creation, pip upgrades, toolkit version checks, package installation, and Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Installer as DeepnoteToolkitInstaller
participant ProcessService as IProcessService
participant Filesystem as Filesystem
Installer->>ProcessService: exec python -m venv { token }
Installer->>ProcessService: exec pip install --upgrade { token }
Installer->>ProcessService: exec deepnote_toolkit version probe { token }
Installer->>Filesystem: check kernel.json exists
Installer->>ProcessService: exec ipykernel install { token }
🚥 Pre-merge checks | ✅ 5 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
ProcessService.exec resolves with partial output when the token kills the process (only shellExec rejects), so forwarding the token exposed several paths that misread a cancelled exec as a domain result: - rethrow CancellationError unwrapped from installVenvAndToolkit's catch so upstream isCancellationError checks suppress the error UI instead of showing an install failure - make isToolkitInstalled cancellation-aware: throw on cancel after the probe exec instead of returning undefined, which misdiagnosed healthy venvs as toolkit-missing and successful installs as failed verification - require the token parameter on isToolkitInstalled so future callers cannot silently reintroduce an uncancellable probe - check for kernel.json rather than the kernelspec directory and re-check the token after the ipykernel exec, so a cancelled install cannot leave a permanently trusted partial kernelspec - re-check the token in installAdditionalPackages before reporting success, and log cancellation instead of a failure message Rewrite the unit test on the repo's ts-mockito pattern (capture/verify, deepStrictEqual per CLAUDE.md) and cover the ensureVenvAndToolkit probe. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/kernels/deepnote/deepnoteToolkitInstaller.unit.test.ts (1)
57-124: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueRepeated
CancellationTokenSourcecreate/dispose boilerplate.All three tests wrap the body in identical
const cts = new CancellationTokenSource(); try {...} finally { cts.dispose(); }. Could extract a small helper/fixture, but with only 3 tests the payoff is marginal.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/kernels/deepnote/deepnoteToolkitInstaller.unit.test.ts` around lines 57 - 124, The three tests in installAdditionalPackages and ensureVenvAndToolkit repeat the same CancellationTokenSource setup/teardown boilerplate, so factor that pattern into a small helper or fixture in deepnoteToolkitInstaller.unit.test.ts. Keep the helper focused on creating the token, running the async test body, and disposing the source afterward, then update the tests to use it while preserving the existing assertions and token forwarding checks.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/kernels/deepnote/deepnoteToolkitInstaller.unit.test.ts`:
- Around line 57-124: The three tests in installAdditionalPackages and
ensureVenvAndToolkit repeat the same CancellationTokenSource setup/teardown
boilerplate, so factor that pattern into a small helper or fixture in
deepnoteToolkitInstaller.unit.test.ts. Keep the helper focused on creating the
token, running the async test body, and disposing the source afterward, then
update the tests to use it while preserving the existing assertions and token
forwarding checks.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f9686885-8346-41c5-abba-80b1b0da61b5
📒 Files selected for processing (2)
src/kernels/deepnote/deepnoteToolkitInstaller.node.tssrc/kernels/deepnote/deepnoteToolkitInstaller.unit.test.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/kernels/deepnote/deepnoteToolkitInstaller.node.ts
Problem
The pip/venv
processService.execcalls in the Deepnote toolkit installer were started without theCancellationToken. Cancellation was only checked between calls, so cancelling during a multi-minutepip installdid nothing until the install finished — the Stop button appeared dead.Fix
Pass the token into every
execcall indeepnoteToolkitInstaller.node.ts(and thread it throughisToolkitInstalled). The process layer already wirestoken.onCancellationRequestedto kill the subprocess, so cancelling now terminates the running install immediately.Testing
exectsccleanOpened as draft pending review.
Summary by CodeRabbit
Bug Fixes
Tests